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ABSTRACT 



A system for virus checking a data object to be downloaded 
to a client device is implemented in a method including the 
steps of retrieving a data object to be downloaded, scanning 
the data object for a computer virus, and downloading the 
data object to the client device if no computer virus is 
detected. 

21 Claims, 5 Drawing Sheets 
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SYSTEM FOR VIRUS-CHECKING 
NETWORK DATA DURING DOWNLOAD TO 
A CLIENT DEVICE 

This application claims the benefit of the identically- 
titled U.S. Provisional Application No. 60/041,002, filed 
Mar. 27, 1997 by Michael M. Tso et al. and assigned to Intel 
Corporation, the disclosure of which is expressly incorpo- 
rated herein by reference. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally in the field of data 
communications for personal computers (PCs), and in par- 
ticular to a system for virus checking content to be down- 
loaded to a network client. 

2. Related Art 

The Internet is quickly becoming the preferred data 
communications medium for a broad class of computer users 
ranging from private individuals to large multi-national 
corporations. Such users now routinely employ the Internet 
to access information, distribute information, correspond 
electronically, and even conduct personal conferencing. An 
ever-growing number of individuals, organizations and busi- 
nesses have established a presence on the Internet through 
"Web pages" on the World-Wide Web ("the Web"). 

As the popularity of the Internet has grown, so too have 
concerns about breaches in system integrity, such as com- 
puter viruses, which may be introduced by data downloaded 
from the largely-unregulated network. Existing virus scan- 
ning utilities typically are installed on end-user systems, but 
this approach presents several disadvantages. First and 
foremost, infected files may still reach a user's system (for 
example, downloaded from the network or copied from an 
external storage device) without the user's knowledge. The 
infected data may reside undetected on the user's system for 
a long period of time (for example, until the next time the 
user does a complete system scan, which many users do no 
more frequently than weekly, if at all). In the meantime, the 
user may inadvertently pass the infected hie to other users. 
In addition, users may forget to leave virus checking soft- 
ware running, thereby providing infected data with an 
opportunity to infiltrate their system, liven a user who is 
diligent about periodically scanning his or her system may 
not be entirely safe from viruses, since the virus checking 
software may be outdated (that is, lacking the latest known 
virus pattern files). 

Many of the disadvantages of existing end-user virus 
cheeking approaches can he avoided by preventing infected 
files from ever being downloaded to an end-user's machine 
in the first place. Accordingly, there is a need for a virus 
checking system capable of efficiently scanning network 
content for viruses prior to downloading such content to 
end-users. 

SUMMARY OF THE INVENTION 
According to an embodiment of the present invention, a 
method for virus checking a data object to be downloaded to 
a client device is provided. Upon retrieval of a data object 
to be downloaded, the data object is scanned for a computer 
virus. If no computer virus is detected, the data object is 
downloaded to the client device. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a schematic diagram illustrating a network 
device configured according to an embodiment of the 
present invention. 



FIG. 2 is a flow diagram illustrating a method for virus 
checking network data according to an embodiment of the 
present invention. 

FIG. 3 is a flow diagram illustrating an alternate method 
5 for virus checking network data according to an embodiment 
of the present invention. 

FIG. 4 is a schematic diagram illustrating a network 
device configured according to another embodiment of the 
present invention. 

FIG. 5 is a schematic diagram illustrating a system for 
transcoding network content to which embodiments of the 
present invention may be directed. 

i5 DETAILED DESCRIPTION 

Embodiments of the present invention are directed to a 
system for virus checking network data to be downloaded to 
a client device, such as data retrieved from an Internet 
content server in response to a browser request. With rcf- 

20 erence to FIG. 1, according to a first embodiment of the 
present invention a client device 12 may access a plurality 
of content servers 7 through a network device 4. Content 
servers 7 may reside, for example, on the Internet; however, 
the present invention is not limited to any particular network 

25 or networking environment. 

In this particular embodiment, network device 4 is a 
network proxy, and may be implemented, for example, as a 
content server or other stand-alone computer coupled to an 
ISP's (Internet Service Provider's) network, a corporate 

30 network, or anywhere on the Internet. Network device 4 is 
capable of providing multiple client devices 12 (only one is 
illustrated) with access to content resident on computers 
coupled to the Internet. In accordance with other 
embodiments, network device 4 may comprise, for example, 

35 a router, a networking stack, or any other device capable of 
performing the functionality described herein. 

In this embodiment, network device 4 includes a virus 
checker 5. Virus checker 5 may comprise any standard, 
off-the-shelf virus scanning application. Such applications 
typically detect viruses through pattern matching or detec- 
tion of certain run-time behaviors associated with known 
viruses. The bit patterns and/or run time behaviors for which 
virus checker 5 scans are typically extensible and stored in 
configuration files accessible by virus checker 5. 

Virus checker 5 may be implemented as a software 
module installed on network device 4 or on a separate device 
(not shown) coupled to network device 4. Virus checker 5 
may alternatively be implemented in a device configured to 

5() provide transcoding services to one or more client devices. 
FIG. 5 illustrates a system for transcoding network content 
to which embodiments of the present invention may be 
applied, as described further below. 

FIG. 2 provides a flow diagram describing a method for 

55 virus checking network data according to an embodiment of 
the present invention. The illustrated method may be 
implemented, for example, using a system such as those 
illustrated in FIG. 1 and FIG. 5. For purposes of illustration, 
the following description makes reference to the structural 

(„, features illustrated in FIG. 1, but the described method may 
be implemented using other structural embodiments. 

As shown in FIG. 2, processing begins upon receipt of a 
request for a data object from client device 1 (Step 20). Such 
a request may comprise, for example, an HTML. (IlyperText 

65 Markup Language) request specifying a particular URL 
(Uniform Resource Locator) associated with a Web page 
resident on content servei 7. Network device 4 then retrieves 
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the requested data object from content server 7, generally in 
the form of an HTML file (Step 30). Once the file is 
completely received, network device 4 invokes virus 
checker 5, which in turn performs its preconfigured virus 
scan processing with the requested file as input (Step 40). If 
the requested file does not contain a virus, network device 4 
transmits the file to client device 1 (Step 70); if a virus is 
detected, the file will not be sent and, optionally, network 
device 4 transmits an appropriate error/warning message to 
client device 1 and/or content server 7 (Step 60). 

In an alternate embodiment, illustrated in FIG. 3, the virus 
checking method may implemented in a manner intended to 
maximize the efficient transfer of data from content server 7 
to client device 12. In a typical network transaction, content 
server 7 will transmit a requested data object as a series of 
contiguous portions. In contrast to the embodiment of FIG. 
2, network device 4 generally transmits those portions to 
client device 1 as soon as they are received from content 
server 7, rather than waiting for the entire data object to be 
received. This mode of operation is similar to that used in 
existing non-virus checking proxies (also known as pass- 
through proxies), and is commonly referred to as "stream- 
ing." Here, however, network device 4 behaves differently 
from such known proxies in that it always withholds a 
portion (or a segment of a portion) of the requested file 
most-recently received from content server 7, and does not 
transmit that withheld portion until at least another 
similarly-sized portion of the requeued lile is received. As 
explained further below, this retained portion of the 
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message or other notification may optionally be sent to 
content server 7 and/or client device 1. 

While the final virus checking is occurring, it is important 
that the communications link 14 from network device 4 to 

5 client device 12, such as a TCP (Transmission Control 
Protocol) socket or other transmission virtual connection, 
remain active to avoid client device 12 discarding the 
partially-transferred file as incomplete. Some client devices, 
however, may be using a communications protocol (for 

10 example, TCP) or other software (for example, a browser) 
which includes a timeout mechanism whereby the commu- 
nications link is automatically terminated if no activity 
between network device 4 and client device 12 is detected 
over a predetermined period of time. Such a timeout feature 
is typically implemented using a protocol stack timer rcsi- 

15 dent on client device 12 which maintains a rolling estimate 
of the anticipated latency for network transactions. Since 
virus checking operations may be time consuming (at least 
more than the average network latency of a typical 
transaction), it may be desirable to "desensitize" [he protocol 

20 stack timer by artificially delaying individual segments of 
the requested file before transmitting them to client device 
12. This will prevent a timeout from occurring at the very 
end of the transaction when the complete file is being 
scanned at network device 4. In such an embodiment, the 

25 amount of delay to be introduced for each individual seg- 
ment may be calculated as follows: 

1. The time required to perform a virus scan on the 
complete lile is first calculated. This is typically a 
function of the size of the file and the type of virus scan 



1, and particularly browser 32, will interpret the requested 
file as corrupt or incomplete if the retained portion is 
missing. For most file types, only the last few bytes need be 
withheld, although to be conservative it may be desirable to 
withhold as much as IK bytes. 

Referring to FIG. 3, as network device 4 is streaming the 
requested file to client device 12, il maintains a working 
copy of the transmitted portions (Steps 190, 220). Virus 
checker 5 performs virus checking (for example, using 
standard pattern scans) on the requested lile as portions are 
received from content server 7, but again this processing 
does not delay the transfer of data to client device 12 (Step 
150). If a virus is detected, network device 4 terminates both 
the transmission from content server 7 and the transmission 
to client device 1 (Steps 200, 210). Network device 4 may 
explicitly notify client device 1 that a virus was detected so 
that any previously-received portions of the requested file 
can be discarded, although in almost all existing file transfer 
applications, such as Web browsers and FT P (File t ransfer 
Protocol) applications, an abnormal termination results in an 
automatic discard of any pai liall\ -Irauslei red lile. 

Assuming virus checker 5 does not first detect a virus, it 
may optionally perform additional virus checking operations 
upon detecting the end of the file being transmitted by 
content server 7 (Steps 160). For example, some existing 
virus checking routines require an entire file. At this point, 
because network device 4 has retained a portion of the 
requested file, client device 12 will not have received the 
entire file. Once the final virus checking is complete, and 
assuming no virus is detected, network device 4 transmits 
the final withheld portion of the requested file to client 
device 12 (Step 210). On the other hand, if a virus is detected 
the withheld portion is not transmitted to client device 1 and 
the transmission is terminated (Step 200). Again, a suitable 



process is then 
applied such that the time delay injected for a segment 
progressively increases in each successive segment. 
The amount of injected delay for all but the last 
35 segment will thus be of the same order of magnitude as 
the time calculated in step "1." above. 
3. This progressive desensitization will not only prime the 
client protocol stack timer for the potentially large final 
delay for scanning the entire file, but will also ensure 
40 that the round-trip estimates maintained by the client 
protocol stack are only gradually increased, thereby 
adding to the stability of the system. 
The foregoing "streaming" embodiments are beneficial 
because they minimize idle time on the communications link 
45 14 between network device 4 and client device 12 by 
keeping communications link 14 full of data for as long as 
network device 4 has data ready to send, thereby reducing 
any user-visible latency introduced by the virus checking 



50 In another variation on the above-described embodiments, 
virus checker 5 may be configured to repair an infected file 
and complete the transmission to client device 12 instead of 
abandoning the entire transaction when a virus is found. 
Such repair functionality is well known in the field of 

55 computer virus checking. To implement this feature, the 
current transaction between network device 4 and client 
device 12 may first be nullified (and the portion of the 
requested file already received by client device 12 
discarded), for example, by terminating the connection or by 

Mi using an alternate predetermined protocol (if client device 
12 is so-enabled) to exchange special data packets informing 
client device 12 that a repaired file will be sent. The repaired 
file may then be safely transmitted to client device 12. Using 
an approach of this type not only utilizes system and 

65 network resources most efficiently, but also adds more value 
to the virus checking operation by providing a disinfecting 
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Referring now to FIG. 4, since virus checking can be a "transcode" refers to virtually any type of addition, deletion 

resource-intensive operation, checked files and/or results of or modification of data transmitted to or from network client 

checks may be advantageously stored in a cache storage 30 12 by or through transcoding server 34. Examples of such 

resident in, or coupled to, network device 4. Future requests transcoding services include data compression, image 

for the same data object may then be serviced immediate!} 5 scaling, and dynamic removal of predetermined content. In 

without having to recheck the file. Network device 4 may the context of the present invention, the provision of 

also include a cache interface 28 configured to check dynamic virus checking may be the only transcoding service 

whether a cached object has been updated on content server provided to a particular client device, or may be only one of 

7 since being cached, in which case network device 4 will a variety of services. 

retrieve the updated file and initiate virus checking as 10 As illustrated in FIG. 5, transcoding server 34 may 

described above. If the virus repairing option is include a transcoder 20 with a parser 22 and a plurality of 

implemented, the repaired data object may be stored in transcode service providers 24. Parser 22 is configured to act 

cliche storage 30. upon data received by transcoder 20, such as a request for a 

As noted above, virus checker 5 will typically maintain a network object generated by client device 12 or a reply to 

file or other data structure containing a collection of virus 1? such a request provided In a content server oi other device 

patterns used to scan data objects. When new virus patterns on network 18. In this particular example, parser 22 is 

are received by virus checker 5, such as through a software responsible for selectively invoking one or more of 

update, network device 4 may have a large collection of transcode service providers 24 based upon a predetermined 

already-examined files in cache storage 30. Given the avail- selection criterion. With reference to FIG. 1 and FIG. 4, 

ability of new virus patterns which have not been used to 20 virus checker 5 may be implemented, for example, as a 

scan these cached files, network device 4 may simply expire transcoding service provider 24. Persons skilled in the art 

all of the cached objects In avoid the possibility that a will recognize, however, that the functionality of transcod- 

now-known virus was missed. Alternatively, according to ing service provider 24 may also be implemented in a router, 

another embodiment of the present invention, network a networking stack, or any other suitable network device, 

device 4 may be configured to update the virus scan of the 25 In the arrangement shown in FIG. 5, transcoding server 34 

cached objects as detailed below. includes an HTTP (HyperText Transfer Protocol) remote 

According to this particular embodiment, objects in cache proxy 36, capable of accessing network 18 over server/ 
storage 30 may include a virus checking status indicator and network communications link 16. HTTP remote proxy 36 
a pattern version number. The pattern version number iden- provides functionality different from known network 
tifies which version of the vims pattern tile was used to 30 proxies, which generally are little more than a conduit for 
derive the virus checking status. If new virus patterns are requests to, and replies from, external Internet resources, in 
communicated to network device 4 as an increment of the that it is capable not only of examining such requests and 
current version of the virus pattern file, virus checker 5 can replies, but also of acting upon commands in the requests by, 
maintain a list of deltas in its pattern file. Then, when a for example, determining whether or not to transcode con- 
request for a cached object is received, virus checker 5 need 35 tent. Moreover, using transcoder 20, HTTP remote proxy 36 
only check the parts of the vinis pattern file that have is capable of changing content received from network 18 
changed since the data object was cached. Assuming no prior to returning it to a requesting network client 12. 
virus is detected, the virus check status and pattern version Looking more closely at the arrangement shown in FIG. 
number stored with the data object would be updated after 5, transcoder 20 is coupled to HTTP remote proxy 36. Parser 
the operation. In a variation on this embodiment, virus 40 22 manages the transcoding of data to be transmitted from 
checker 5 may systematically check all of the cached objects transcoding server 34 to network client 12. To this end, 
to bring them up to date after new virus patterns are parser 22 controls transcode service providers 24 to selec- 
received. tively transcode content based on a predetermined selection 

By way of further illustration, and with reference again to criterion. For example, one or more transcode service pro- 
FIG. 5, embodiments of the present invention such as those 45 viders 24 may provide the capability to compress and/or 
described above may be implemented, for example, as part scale different types of data content, such as image, video, 
of asystem for dynamically transcoding network content. As or HTML (HyperText Markup Language), in addition to 
illustrated, network client 12 communicates with an external providing the virus checking functionality as discussed 
network 18 through a transcoding server 34. Network client above. Transcoding server 34 may also include a server-side 
12 includes a browser 32, such as the Netscape Navigator 50 cache memory 30 managed by a server-side cache interface 
v.3.0 browser (although the invention is not limited in this 28. Server-side cache memory 30 may be used to store both 
respect), which manages the presentation of data to a user. original and transcoded versions of content for later trans- 
In the illustrated arrangement, network client 12 is "non- mission to network client 12 without the need to re-retrieve 
enabled," meaning no specialized transcoding software is the content from network 18 or to re-transcode the content, 
preloaded on network client 12. Network 18 may comprise, 55 Parser 22 may comprise a relatively simple, uniform 
for example, the Internet. In this particular arrangement, interface to HTTP remote proxy 36, and may provide an API 
network client 12 communicates requests for information to, (Application Programming Interface) for transcoding data 
and receives information from, transcoding server 34 over a received by HTTP remote proxy 36. Parser 22 manages one 
client/server communications link 14. Transcoding server 34 or more transcode service providers 24 that are accessed 
in turn communicates with computers resident on network 60 through a common SPI (Service Provider Interface). In this 
18 through server/network communications lirrk 16. The particular implementation, parser 22 is designed in comp Ir- 
respective communications links 14, 16 may comprise any ance with the Windows Open Systems Architecture 
suitable communications media known in the art. (WOSA), and may be implemented as a Win32 DLL 

Transcoding server 34 may be configured to provide a (Dynamic 1 ink I .ibrary). The W< )SA architecture, described 

wide variety of transcoding services to network client 12 65 in Readings on Microsoft Windows and WOSA (Microsoft 

and/or network devices, such as content servers, with which Corp. 1995), enables additional transcode service providers 

network client 12 communicates. In this context, the term 24 to be dynamically added to the system to provide new 
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features and/or better transuding algorithms, while al the 
same time not requiring changing or retesting other software 
components in the system. 

Like parser 22, server-side cache interface 28 may be 
modeled after a standard Get Set interface. Server-side . 
cache memory 30 essentially "owns" all cached objects, in 
that it manages the properties and storage of the objects and 
may invalidate any oon-locked object at any time; however, 
the actual format of any given cached object is known only 
by parser 22 and its associated transcode service providers 
24. Thus, for data integrity and transcoding efficiency 
purposes, all access to server-side cache memory 30 in this 
arrangement is through parser 22. 

In operation, transcoder 20 may use a Read( ) call to read 
data from a specified cached object data stream. For 
example, transcode service provider 24 may invoke this call 
and tunnel stream data through HTTP remote proxy 36 
directly to network client 12. Similarly, a Write( ) call may 
be used to cache data from a new HTTP data stream. This 
call will append an incoming data stream received from, for 2 
example, a Web server or transcode service provider 24, to 
an opened cache stream which may be concurrently read 
using the Read( ) call. 

Parser 22 may be configured to include the following 
calls: 



t.ctt*jcd(l:Kl..lnl';i,;ims..V;()ull';u;ims..V;()ulsii l ;ini. . . . :: 

CiclSot IcdObjeclfURI J iPamins,&OutParairis,&OiitStream,Stage, . . . ) 

PutObject(LIRI.,[nl > aiaiiis.niel.^lnsiKan].^Oi tl'anm.&OitStra n\ 



Parser 22 may use such calls to manage the provision of 
requested content to network client 12. For example, the 
GetObject( ) call may be used to service non-enabled client 
requests, and returns a non-transcoded (original) version of 
a specified hypertext object. In this arrangement, transcod- 
ing server 34 assumes that each HTTP request has a unique 
thread that may be blocked until the request is satisfied. 
Accordingly, the GetObject( ) call will block until it either 
returns the requested data stream or indicates failure with a 
cause (e.g., object does not exist). This ability to return a 
so-called standard hypertext object is advantageous for 
compatibility reasons, enabling embodiments of the present 
invention to be used with existing browsers that do not 
include support for certain transcoding functionality (e.g., 
advanced data compression), and enabling users to selec- 
tively retrieve non-transcoded versions. 

The GctScalcdObject( ) call is similar to (ietObjcct( ), and 
is also used to request an object from server-side cache : 
memory 30; however, it adds support for requesting a 
particular version of that object, such as a high-quality 
rendition. Unlike traditional caching proxies, transcode ser- 
vice providers 24 can use server-side cache memory 30 to 
store several different versions of an object to support clients . 



be placed intc 
appropriate transcode s 
example, on tl 



with different communications and/or pre 
ties. Thus, an additional "Stage" parameter n 
indicate which version of the cached object is 
to network client 12. Where transcode service 
configured to scale network content, it may u 
eter to request a version of a cached objei 
example, a default scaled quality, a refinement t 
quality version, or the original non-scaled version. 

In this particular arrangement, when network client 12 
requests a hypertext object, HTTP remote proxy 36 uses - 
either the GetObject( ) or GetScaledObject( ) call 
(depending on if network client 12 is capable of receiving 



ay be uLd to 
o be returned 
provider 24 is 
e this param- - 
t having, for 



scaled/transcoded datatypes) to retrieve the hypertext object 
from parser 22. If the hypertext object is not found, parser 
22 uses the CreateEntry( ) call to create an entry (in effect, 
a placeholder) in server-side cache memory 30 for the new 
object. The new entry is returned to HTTP remote proxy 36, 
which requests the hypertext object from network 18. As a 
data stream for the hypertext object is returned, HTTP 
remote proxy 36 calls parser 22 using the PutObject( ) call, 
passing into this call the new entry and the handle to the data 
the entry. Parser 22 selects an 
ervice provider 24 based, for 
type of the data stream. In this 
context, the term content type encompasses a datatype, an 
HTTP MIME (Multipurpose Internet Mail Extensions) type, 
a content format, and so on. The selected transcode service 
provider 24 uses a separate thread to read the incoming data 
stream, transcode it (for example, scan for predetermined 
content and delete it if found), and place it within the entry 
of server-side cache memory 30. The current thread imme- 
diately returns to HTTP remote proxy 36, which once again 
calls GetScaledObject( ) (or GetObject( )). This case will 
always result in a cache hit. This thread then works simul- 
taneously with the separate thread in the PutObject( ) to 
tunnel data (either original or transcoded) from transcoding 
server 34 to network client 12. 

Embodiments of the present invention may be distributed, 
for example, as a set of instructions residing on a storage 
medium. Such a storage medium might be a memory of a 
computer; a piece of firmware; a portable storage device, 
such as a diskette or other magnetic storage device, or a 
CD-ROM; or any other medium on which it is known to 
store executable instructions. 

Although the present invention has been largely described 
with reference to embodiments for processing requests for 
data from the Internet, persons skilled in the art will recog- 
nize that it is equally applicable to other networking envi- 
ronments. For example, embodiments of the present inven- 
tion may be used to scan files transmitted between devices 
over an intranet (typically a secure corporate network), or in 
an ISP environment where dial-up users get access to the 
network operated by an independent service provider. In 
such environments, network requests generated by users 
(either all users or a select group) that require secure access 
are forced to go through a virus checker such as that 
disclosed herein in a manner similar to what is currently 
done for setting up firewall proxies. Existing technology, 
such as router filters, may be used for this purpose. Such an 
arrangement is beneficial in that it provides increased safety 
from infected network data. 

The foregoing is a detailed description of particular 
embodiments of the present invention. The invention 
embraces all alternatives, modifications and variations that 
fall within the letter and spirit of the claims, as well as all 
equivalents of the claimed subject matter. For example, the 
virus checking functionality may be distributed between a 
client device and a network device, or distributed among a 
plurality of network devices. Likewise, virus checking may 
be provided as one of a number of different transcoding- 
related services dynamically provided by a network proxy or 
similar device. Persons skilled in the art will recognize from 
the foregoing detailed description that many other 
alternatives, modifications and variations are possible. 
What is claimed is: 

1. A method for virus checking a data object to be 
downloaded to a client device, said method being imple- 
mented on a network device coupled to the client device by 
a communications link, said method comprising the steps of: 
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retrieving a data object to be downloaded to the client 

scanning the data object for a computer vims; and 
downloading the data object to the client device if no 
computer virus is detected, w herein the data object is 
segmented into a series of contiguous portions, said 
retrieving, scanning and downloading steps being per- 
formed for each of said contiguous portions. 

2. The method of claim 1, further comprising the step of 
returning an error to the client device if a computer virus is 
detected. 

3. The method of claim 1, wherein the network device is 
coupled to a server device, said method further comprising 
the step of returning an error to the server device if a 
computer virus is detected. 

4. The method of claim 1, further comprising the step of 
withholding al least a segment of one of said contiguous 
portions from the client device until all of said contiguous 
portions of the data object have been scanned. 

5. The method of claim 4, wherein absence of said 
withheld segment has a sufficient magnitude to cause the 
client device to interpret the data object as incomplete. 

6. The method of claim 4, wherein the client device 
includes a timeout mechanism for terminating the commu- 
nications link if no activity is detected for a predetermined 
period of time, said method further comprising the step of 
extending said predetermined period of time to avoid a 
timeout while the network device is virus checking the data 

7. The method of claim 6, wherein said timeout mecha- 
nism comprises a protocol stack timer, said step of extending 
said predetermined period of time comprising a desensiti- 
zation of said protocol stack timer. 

8. The method of claim 7, wherein said desensitization is 
achieved by introducing a progressively greater delay into 
the download of each of said series of contiguous portions. 

9. The method of claim 1, further comprising the step of 
repairing the data object prior to downloading it to the client 
device if a computer virus is detected. 

10. A network device for virus checking a data object to 
be downloaded to a client device, said network device 
comprising a computer programmed to: 

retrieve a data object to be downloaded to the client 
device; 

scan the data object for a computer virus; and 
download the data object to the client device if no 
computer virus is detected, wherein the data object is 
segmented into a series of contiguous portions, said 
retrieval, scan and download being performed for each 
of said contiguous portions. 

11. The network device of claim 10, wherein said network 
device comprises a proxy. 
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12. The network device of claim 10, wherein the computer 
is programmed to perform the additional step of repairing 
the data object prior to downloading it to the client device if 
a computer virus is detected. 
5 13. The network device of claim 10, wherein the computer 
includes a cache storage, said computer being further pro- 
grammed to perform the steps of: 

retrieving a cached version of the data object if one 
10 resides in the cache storage; and 

storing a version of the data object in the cache storage if 
no computer virus is detected. 

14. The network device of claim 13, wherein said version 
of the data object stored in the cache storage identifies a 

15 computer virus for which the data object was scanned. 

15. The network device of claim 13, wherein said com- 
puter is further programmed to perform the step of storing a 
repaired version of the data object in the cache storage. 

16. The network device of claim 10, wherein said network 
2U device comprises a router. 

17. A storage medium containing a set of instructions for 
execution by a network device coupled to a client device, 
said set of instructions comprising instructions for: 

25 retrieving a data object to be downloaded to the client 

scanning the data object for a computer virus; and 
downloading the data object to the client device if no 

computer virus is detected, wherein the data object is 
30 segmented into a series of contiguous portions, said 

retrieving, scanning and downloading being performed 

for each of said contiguous portions. 

18. The storage medium of claim 17, wherein said storage 
medium comprises a magnetic storage device. 

19. The storage medium of claim 17, wherein said storage 
medium comprises a memory accessible by the computer. 

20. The storage medium of claim 17, wherein said set of 
instructions further comprises instructions for repairing the 

40 data object prior to downloading it to the client device if a 
computer virus is detected. 

21 . A system for virus checking network data, said system 
comprising a client device coupled to a network device by 
a communications link, wherein said network device is 

45 programmed to retrieve a data object to be downloaded to 
the client device, scan the data object for a computer virus, 
and download the data object to the client device if no 
computer virus is detected, the data object being segmented 
into a scries of contiguous portions, with the retrieval, scan 

50 and download being performed for each of the contiguous 
portions. 
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